Repository navigation
fix(picker,#18866): elargir la fenetre last_delivery en mode --belt + fusionner le rappel rouge dans le JSON du tapis (v2, merge-base origin/main) - #18882
Conversation
… fusionner le rappel rouge dans le JSON du tapis Le tapis (`--belt`) sert la file par derniere-livraison croissante. La fenetre de fetch fusionnee (14 j par defaut, portee par `series_saturation`) oublie toute livraison au-dela : une issue livree il y a 16 j tombe derriere une vieille jamais servie, alors qu'elle a recu du travail re-cent et qu'elle merite d'etre reprise. La reorganisation en `belt_sort_key` la reclasse alors a sa date de creation, ce qui contredit la regle du tapis. Deux corrections bornees : 1. Nouvelle constante `BELT_WINDOW_DAYS = 90` (90 j, couvre un tour complet au regime lent 10-20 grains/jour). Le fetch_MAX commun a 400 PRs borne le corpus, donc la fenetre ne fait pas exploser le fetch -- si elle depasse 400 PRs, le tapis sert avec ce qui rentre, comme la volee ponderee aujourd'hui. 2. Mode `--belt --json` : le rappel rouge/WIP etait imprime en double (deux objets JSON sur la sortie standard). `json.loads` se cassait sur `Extra data`. Le rappel est mis sous la cle `repair` du document du tapis, la sortie reste UN document parseable. Les tests couvrent les 3 cas : belt+json+red -> repair non-None, belt+json sans red -> repair=None, json+red hors belt -> mode repair standalone inchange. Tests : 3 nouveaux dans `test_pick_idle_grain_belt.py`. Suite `pick_idle_grain*` + `series_saturation` : 255 passes, 0 regression. Co-Authored-By: Claude Haiku 4.5 (1M context) <noreply@anthropic.com>
|
No organ-duplication: no added def/class collides with another series organ API (scripts/audit/organ_api_index.yaml). Detector: |
|
G-VAR-2/3 GENRE signals (advisory, non bloquant, #10020).
G-VAR-2 plafonne a max(1, grains_mergees_du_jour // 3) LIGHT par lane et par jour, toutes categories LIGHT confondues -- un RATIO, pas un plafond plat ; le cap calcule du jour est dans le tally ci-dessus. G-VAR-3 interdit deux genres LIGHT consecutifs. Les signaux ci-dessus rendent le fait VISIBLE (labels |
|
closing-keyword + PR-number reference(s) that would auto-close a PR on squash: [' GitHub interprète Le discriminateur est la nature du numéro, pas le contexte du mot-clé : Pour passer ce gate :
|
Path-collision (organ #13359/#13615)Cette PR #18882 (
Le verdict terminal (#15578) signale qu'un cote de la paire est deja sur |
|
[ADJOINT PREFLIGHT] note: Premier dossier c368. fix(picker,#18866) elargir la fenetre last_delivery en mode --belt (14j -> 90j) et fusionner le rappel rouge/WIP dans la cle repair du document JSON belt (au lieu de doubler la sortie). 3 fichiers : scripts/series_saturation.py (+13), scripts/pick_idle_grain.py (+45/-19), scripts/tests/test_pick_idle_grain_belt.py (+129). 3 nouveaux tests couvrant les 3 cas de sortie. Migration depuis #18869 (CONFLICTING) faite par cherry-pick 9401d6c sur origin/main, 1 seul commit, pas de charrie. Lane porteuse myia-po-2024:CoursIA-2 (DIFFERENTE de ma lane :CoursIA-3). Crible de fond : pas de code jete, pas de re-execution notebook, pas de hand-edit de sortie. PR gate success a 22:32:21Z, 0 fails, B.0 rc=0. MED/guard -> merge_ready eligible, dossier tiers debloque. |
…json, repair key) (#18897) The Vibe lanes still opened their choice with the weighted draw. Now that #18882 gives a single JSON document, switch them to the belt: P0 is read under the repair key, picks are taken in order, and a skip needs a real barrier (outside the Vibe profile, or G-VAR-3). Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Grain: MED/guard -- lane myia-po-2024:CoursIA-2 -- prev: DEEP/notebook-python #18791
Résumé
Deux corrections bornées au mode
--beltdepick_idle_grain.py(#18832), levées comme suit :1. Fenêtre
last_deliveryétendue à 90 j en mode--beltConstat :
last_delivery_per_issueest appelé avecdays=DEFAULT_WINDOW_DAYS(14 j, partagé avec la volee ponderee). Une issue servie il y a plus de 14 jours n'a pas delast_delivery_stamp, doncbelt_sort_keyla reclasse a sa date de création -- comme si elle n'avait jamais été servie. Une vieille issue servie il y a 15-30 jours passe alors devant une issue de juin-aout que personne n'a jamais servie. La regle de #18832 veut l'inverse.Correction : nouvelle constante
BELT_WINDOW_DAYS = 90dansseries_saturation.py. La fenetre par defaut reste a 14 j (mode nominal), le tapis bascule sur 90 j. 90 j couvre un tour complet au regime lent (10-20 grains/jour font un tour en 25-50 j sur 500 issues), et le plafondMERGED_FETCH_LIMIT = 400borne le corpus -- si la fenetre depasse 400 PRs, le tapis sert avec ce qui rentre.2. Sortie
--jsonen UN seul documentConstat : la branche rouge du
main()faisaitprint(json.dumps(...))puis retournait 0 sans condition surargs.belt. Le tapis re-imprimait son propre JSON juste apres. Le consommateur lisait DEUX objets, etjson.loadslevaitExtra data.Correction : en mode
--belt, le rappel rouge/WIP est mis sous la clerepairdu document du tapis. La sortie reste UN document parseable. Trois cas :--belt --jsonmode: "belt",repair: {...}non-None--belt --jsonmode: "belt",repair: null--json(hors belt)mode: "repair", doc standalone (contrat inchange)Fichiers
scripts/series_saturation.py: ajoutBELT_WINDOW_DAYS = 90(+ commentaire de justification). +13/-0.scripts/pick_idle_grain.py: importBELT_WINDOW_DAYS, bascule de la fenetre en mode belt, refactor du blocred_hit/wip_hitpour fusionner le rappel dans la clerepairdu document belt. +45/-19.scripts/tests/test_pick_idle_grain_belt.py: 3 nouveaux tests couvrant les 3 cas. +129/-1.Diff total : 3 fichiers, +187/-20 (PR effective propre, aucun charrié de la base).
Note de migration : la PR d'origine (#18869) avait une merge-base sur 99e4e05 (avant les merges #18836 mode --belt et #18832) ; la branche d'origine
fix/18866-belt-window-and-jsoncomportait 9 commits dont 8 etaient des commits de #18836 rejoués en double. Cette nouvelle PR a été obtenue pargit cherry-pick 9401d6c29esurorigin/main-- un seul commit, diff minimal, pas de charrié.Tests
Aucune régression.
Contrôle du constat #1203
Le correctif #1 devrait sortir #1203 de la tête du tapis (cf. contrôle du body de l'issue : son
last_delivery_stampdoit valoir au moins2026-09-09).Non testé en CI ici (PR mergée dans une autre timeline) ; le test de la constante
BELT_WINDOW_DAYS = 90est indirect viapick_idle_grainqui utilisedelivery_window_dayspartagé entre les deux modes. Vérification à faire au prochain passage de la lane qui ouvre--beltsur la prod.Recouvrement avec #18870
ai-01 signale un recouvrement avec PR #18870 (tete
4bfd737071) qui modifie aussiscripts/pick_idle_grain.py(+12/-2) etscripts/tests/test_pick_idle_grain_belt.py(+40/-1). Les changements sont sur des fichiers communs mais sans intersection directe dans cette PR :BELT_WINDOW_DAYS(sourceseries_saturation.py, consommee parpick_idle_grain.pypour la fenetre du tapis en mode--belt) et refactore le blocred_hit/wip_hitdumain();belt_filter(filtre du tapis, deja present) pour appliquer le parametreurns=(cf. garde P0 -- la fermeture d'issue est tiree au sort par le picker, pas routee : 21 fermetures MiniMax contre 4 du coordinateur, et l'adjoint n'existe dans aucune regle #15069).Le parametre
args.urnsest deja gere parbelt_filterdans la base. Ma PR ne touche pasbelt_filter. La fusiongit merge origin/main(sans rebase) preserve les deux changements.Liens
fix/18866-belt-window-and-json(merge-base 99e4e05, charrié) → cette PR surfix/18866-belt-window-and-json-v2(merge-base origin/main, propre)CHANGES_REQUESTEDde ai-01 sur feat(picker,#18832): mode --belt (tapis roulant) -- servir les issues par date de derniere visite, sans loterie ni refus #18836 (review 5391008313, point 4).Closes #18866
🤖 Generated with Claude Code
Co-Authored-By: Claude Haiku 4.5 (1M context) noreply@anthropic.com